Object-oriented programs, such as those written in Java, often incorporate classes or other resources that reside in existing libraries. The Java environment provides a means for loading such libraries on demand at runtime.
Runtime loading of library code in Java is achieved using software objects known as “classloaders.” Classloaders are adapted to obtain referenced library code, organize the code into classes (if necessary), and make the code available to software that references the library.
When library code is needed multiple times by a Java program, its classloader loads the library only once and caches it for future requests. A single Java runtime environment, however, often runs multiple applications at the same time, each of which is typically provided with its own classloader. Moreover, larger applications may instantiate multiple classloaders for different program components. When two applications or components require the same library code, their classloaders each load a copy of it into memory. This duplication requires additional memory and may significantly affect system performance.
A typical prior art scenario illustrating this problem is depicted in FIG. 1. Shown in FIG. 1 is a Java runtime environment 100 that contains an application server 102 built on top of an object request broker (ORB) 104. Several applications 106 are deployed in application server 102. One or more of applications 106, such as application 106c in the particular example of FIG. 1, may also be containers for other applications 108. Also shown in FIG. 1 is a security provider 110 running in the same Java runtime environment 100, and built on top of an encryption engine 112.
As is further shown in FIG. 1, each application 102-112 in environment 100 is provided with its own classloader 114 adapted to serve resources required by its respective application. Moreover, in the exemplary scenario of FIG. 1, each application 102-112 references the same XML parser library, xml.parser.jar. Consequently, at run time, multiple copies of this XML parser library are loaded into memory, one by each classloader 114. As noted, this duplication consumes memory and negatively affects performance.
One possible approach for solving this problem might be to provide a single classloader for two or more applications. The shared classloader could examine the source code of both applications and identify all libraries referenced by both. It could then load a single copy of such common libraries for use by both applications.
This approach, however, suffers from several drawbacks. First, if the first and second applications require different versions of the same library, the classloader may load a version of the library not compatible with one of the applications.
Second, sharing a classloader in this way permits each application to load all classes and resources of the other application. Consequently, if one of the applications is malicious, it may harm the second application by, for example, creating instances, making invocations, or examining data of the second application.